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(57) An adaptation mechanism monitors, maintains 
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among end-systems in a distributed PBX topology, 
thereby providing an enhanced Quality of Service (QoS) 
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Description 

[0001] The present invention relates to an adaptation 
mechanism which can be used to monitor, maintain and 
control quality of voice-grade for communications 
among end-systems in a distributed PBX topology, 
thereby providing an enhanced Quality of Service (QoS) 
for the network. 

[0002] As shown in Fig. 1, a communication system 
100 for an entity, such as a corporation, office, or home, 
would' include a voice network 110, such as a private 
branch exchange (PBX), or a group of PBX's connected 
or communicating with each other or to a central office, 
and a data network 120, such as computers 125 con- 
nected to each other over an Intranet and to the Internet. 
PBX 110 is a network that allows many voice devices 
1 1 5 to share a lesser number of outside lines (e.g., trunk 
lines) for making external voice calls. Internal wiring in 
PBX 1 1 0 permits users within the entity to contact each 
other without sending information outside of the entity. 
[0003] As shown in Fig. 2, an entity may wish to con- 
nect voice devices 115 and computers 125 on a single 
network 200 for communication internally and externally 
to the Internet. In other words, voice network 110 and 
data network 120 would merge into a single network 
200. Typically, network 200 digitizes the data from the 
voice devices into, for example, G.711 format, and 
sends all digital data, including the voice traffic, over net- 
work 200. In other words, network 200 would use the 
same manner of transmission between computers 1 25 
and add additional processing to transmit data from the 
voice devices. 

[0004] Fig. 3 illustrates a typical voice and data net- 
work 200. Fig. 3 includes a data network, such as a local 
area network (LAN), based voice switch (PBX) for trans- 
mission of voice data over a data link 31 0 using Internet 
protocol (IP). Voice devices, such as internal phones 
and external lines, are connected to a respective line 
card 320 or trunk card 330 contained in a remote or ex- 
pansion cabinet 340 including a remote CPU 350 or 
shelf controller, via a respective line or channel. The 
cards 320 and 330 are selectively loaded into one of a 
plurality of slots 355 in expansion cabinet 340. Although 
a single expansion cabinet 340 is shown in Fig. 3, the 
PBX could include several expansion cabinets 340, Da- 
ta link 31 0 connects expansion cabinet 340 to a switch- 
ing matrix 360. Switching matrix 360 routes information 
from voice devices to other voice devices, internally 
through line cards 320 and externally through trunk 
cards 330. A process running on a master CPU 390 con- 
figures the present state of the switching matrix 360 over 
its backplane 380. Alternatively, master CPU 390 could 
be located apartfrom switching matrix 360 and the proc- 
ess running on master CPU 390 can configure switching 
matrix 360 over data link 310. Although each of the 
cards are shown as being loaded into an expansion cab- 
inet 340, which is remote from the switching matrix 360, 
another implementation could include some cards in the 



same location, or physical cabinet, as master CPU 390. 
A computer 1 25 can also be connected to data link 31 0. 
[0005] Master CPU 390 and remote CPU 350 cause 
packets of a defined size to be created for transmission 
5 over data link 310. These packets include information 
used to route the packet to a destination and the voice 
or data information. Fig. 4 illustrates a format of a typical 
packet 400 using an Ethernet data link 31 0. Packet 400 
can include, for example, six bytes of a destination ad- 
w dress 410, six bytes of a source address 420, 2 bytes 
of an indication of an ether type 430, a number of bytes 
of a data packet 440, containing data from multiple voice 
devices, and 4 bytes of frame check sequence (FCS) 
data 450. Data packet 440 includes header information 
'5 for the transmission protocol, such as 20 bytes of IP 
header information 441 and 4-20 bytes of UDP/TCP 
header information 442, and data 443 for N channels. 
Typically, the PBX sends 8000 packets per second that 
include voice data. 

[0006] Again referring to Fig. 3, to initiate a call to a 
destination voice device, a source voice device signals 
a source card (e.g., line card 320 or trunk card 330) to 
send a message to switching matrix 360. Switching ma- 
trix 360 sets the switching fabric of the network to create 
a link between the source and destination voice devices. 
When a call is initiated by a device on remote cabinet 
340 by the device going off hook, a message is sent by 
the source device on remote cabinet 340 to a call server 
process running on master CPU 390 indicating that it is 
off hook. The call server process configures switching 
matrix 360 to connect the source device on remote cab- 
inet 340 to a channel that provides a dial tone to the 
newly active device. When dialing begins at the source 
device on the remote cabinet 340, indicating a desired 
destination to contact, another message identifying the 
dialed destination is sent to the call server process run- 
ning on master, which, in turn begins evaluating the di- 
aled number to determine if it is valid. If the call server 
process determines that the number is valid, it then be- 
gins searching for the requested destination device. 
When the destination device is found, the call server 
process instructs the switching matrix 360 to establish 
a connection between the source and destination devic- 
es via switching matrix 360, thereby establishing a two- 
way speech path. 

[0007] Fig. 5 illustrates a typical switching matrix 360 
for parsing and creating a packet. A multiplexer/demul- 
tiplexer 500 receives and sends IP packets over data 
link 31 0. When receiving IP packets, the multiplexer/de- 
multiplexer 500 takes the sequentially ordered channels 
and puts them into parallel order and sends this infor- 
mation to the switch 51 0. Conversely, when transmitting 
IP packets, the multiplexer/demultiplexer 500 takes the 
parallel ordered channels from the switch 510 and plac- 
es them in sequential orderto be included in an IP pack- 
et. Multiplexer/demultiplexer 500 outputs parallel data 
to a switch 510 or creates an IP packet. A table in switch 
510 determines the channel positions in an IP packet. 
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Of course, in non-blocking mode, each voice device in 
the network will have a channel available for assignment 
by the switching matrix. 

[0008] Fig. 6 illustrates a table consistent with a typi- 
cal system for creating and parsing a packet. Table 600 
provides a position index that shows where the data for 
each channel of, e.g., a network will be found in a pack- 
et. Although the packet positions are shown in groups 
of eight in Fig. 6, this is merely for the purpose of illus- 
tration. As shown in Fig. 6, all N channels of the network 
are presumed to be carrying information, regardless of 
whether the channel is active (off-hook), or even if a 
voice or data device is connected to the network at all. 
[0009] Since a number of channels are typically un- 
used, packets created using table 600 include superflu- 
ous information forthe-unused channels, e.g., all zeros. 
In other words, the size allocated channels within the IP 
packet will be all zeros. This wastes the limited band- 
width of the network of Fig. 5. Bandwidth is the amount 
of traffic, in bits per second, that can be transmitted over 
a network. The size of packets and the rate at which the 
network sends the packets determines the bandwidth 
required for the application. Because each voice chan- 
nel typically consumes 64 kilobits/second in an uncom- 
pressed format, if network 200 included a PBX having 
1000 channels, network 200 would require at least 64 
Megabits/second of bandwidth to transmit voice traffic. 
This is significant because data link 310 typically has a 
100 Mbit/second bandwidth and, thus, voice traffic 
would consume almost two-thirds of the available band- 
width, 

[0010] When such a large amount of the bandwidth is 
devoted to voice traffic, the network must spend much 
of its time processing the packets, which could yield very 
little information when many channels are inactive. 
Some data networks contain systems other than those 
carrying voice information. These systems also share 
the network's available bandwidth, consequently, hav- 
ing so much bandwidth devoted to voice traffic negative- 
ly impacts the overall network. For example, devoting 
such large amounts of bandwidth to voice traffic results 
in network congestion, leading to undesirable conse- 
quences such as delayed transmission, retransmission, 
and, indeed, losing packets altogether. 
[001 1 ] To reduce the amount of bandwidth devoted to 
voice traffic, insertion and deletion of cards connecting 
voice channel lines could be detected. Under this solu- 
tion, however, all channels on inserted cards are trans- 
mitted across the network regardless of whether the 
channels are active or not, which is still inefficient utili- 
zation of bandwidth. In addition, this solution provides 
no bandwidth optimization when the network is fully 
loaded, i.e., when the maximum number of cards have 
been inserted. ■ 

[0012] To reduce the amount of bandwidth devoted to 
voice traffic, only channels that are active could be in- 
cluded in a changing table and packets would only trans- 
mit information regarding the active channels. Such a 



table must be updated on a real-time basis to define 
which calls are active and their position index, requiring 
additional CPU time or a faster CPU to reduce the im- 
pact of the real-time processing. In addition, additional 
5 synchronization messages must be sent and confirmed 
whenever a call is made or released to maintain the ta- 
bles at the source and destination in synchronization. 
These synchronization messages consume some of the 
saved bandwidth. 
w [0013] Therefore, there is a need to efficiently reduce 
the amount of bandwidth required to transmit voice data 
in a network, using a minimum amount of additional 
hardware and processing, and a need to do so regard- 
less of the number of active voice devices connected to 
the network. 

[001 4] An example of a bandwidth saving system and 
method using card detection is described in copending 
U.S. Patent Application Serial Number 09/474,779. An 
example of a bandwidth saving system and method us- 
ing a changing table is described in copending U.S. Pat- 
ent Application Serial Number 09/474,778. 
[0015] Recently, many efforts have been devoted by 
the Internet community to investigate transport mecha- 
nisms capable of guaranteeing Quality of Service (QoS) 
requirements for datagram networks (such as, for ex- 
ample, Internet Protocol (IP) networks). The objectives 
include alternatives to the transport of voice, video and 
multimedia by classic Telephone/ISDN and ATM net- 
works. The basic problem is how to guarantee band- 
width, latency (delay) and packet loss, required by voice 
and video, in datagram network architecture. 
[001 6] Communication links between PBXs require a 
fairly large bandwidth for operation on data networks. 
Maintaining this amount of bandwidth is expensive and 
often results in degradation in the overall quality of serv- 
ice among all applications running on the network. 
Known solutions to the problem include attempting to 
reserve bandwidth using approaches such as Resource 
reservation Protocols (RSVP) or policy management 
systems. 

[0017] In addition, approaches to maintaining voice 
quality, such as setting up a fixed Packet Delay Variation 
(PDV) buffer size is not ideally suited to Internet Protocol 
(IP) Networks in which messages flow in a bursty, rather 
than uniform, manner. If the buffer size is too small, the 
most recently arriving data will overflow and the preced- 
ing data is lost. If the buffer is too large, there will be 
gaps, resulting in breaks between message packets. At- 
tempts to set the buffer size at periodic intervals is a te- 
dious process due to the redundancy of the traffic flow, 
and is usually based on trial and error. 
[001 8] Until now, the main obstacle to implementation 
of an adaptable QoS monitoring mechanism from an ap- 
plication prospect has been the manner in which meas- 
urements are obtained. Several algorithm-based solu- 
tions have been proposed, including using the Internet 
Control Message Protocol (ICMP). This, however, has 
been shown to produce not very accurate measure- 
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invention; 

FIGS. 1 0a-1 Oc are flow charts showing the steps of 
one embodiment of channel allocation and deallo- 
cation; 

5 FIGS. 1 1 a-1 1 d illustrate the contents of a message 
sent in the network based on active communication 
detection; 

FIGS. 1 2a-1 2c illustrate the contents of a message 
sent based on channel groups using active commu- 
10 nication detection; 

FIG. 13 illustrates the contents of a group of FIG. 
12a-12c; 

FIGS. 1 4a-14b illustrate the contents of a message 
sent in the network when groups are deallocated 

*s based on active communication detection; 

FIG. 15 illustrates the contents of a message sent 
over the network based on active channel reorder- 
ing to deallocate channel groups; 
FIG. 16 is a flow chart of steps of the process for 

20 transmitting a message consistent with the present 
invention; 

FIG. 17 is a table used to establish channel posi- 
tions in an IP packet sent in the network of FIG. 7; 
FIG. 18 illustrates transmission of an IP packet from 

25 a remote cabinet to a master cabinet consistent with 
the system of FIG. 7; and 
FIG. 19 illustrates transmission of an IP packet from 
a master cabinet to a remote cabinet consistent with 
the system of FIG. 7. 

30 FIG. 20 illustrates a PBX telephone system com- 
prised of PBX main and expansion cabinets con- 
nected via a data network; 
FIG. 21 illustrates the transmission of voice packets 
in a main or expansion cabinet; 

35 FIG. 22 illustrates the reception of voice packets in 
a main or expansion cabinet; 
FIG. 23a illustrates operation of a packet loss coun- 
ter; 

FIG. 23b further illustrates operation of a packet 

^0 loss counter; 

FIG. 24 is a diagram showing operation of packet 
round trip time calculation; 
FIGS. 25a-25b illustrate operation of bandwidth op- 
timization using idle card elimination; 

^5 FIGS. 26a, 26b and 26c illustrate operation of band- 
width optimization using priority-based card-elimi- 
nation; 

FIG. 27 is a flowchart detailing operation of a packet 
loss counter and system reaction; 
50 FIG. 28 is a flow chart showing operation of packet 
delay variation measurement and system reaction; 
and 

FIG. 29 is a flow chart diagram showing implemen- 
tation of bandwidth optimization. 

55 



ments, has real-time impact on performance of the sys- 
tem, and adds more traffic to the network. The added 
traffic overhead is directly proportional to the level of ac- 
curacy being sought for the measurements. 
[0019] Moreover, many real-time operating systems 
(RTOS) do not support multiple applications which use 
raw sockets (used mainly for ICMP). This usually results 
in interference between applications attempting to use 
the sockets. 

[0020] Nor is using the Transmission Control Protocol 
(TCP) or the User Datagram Protocol (UDP) always ac- 
ceptable, since these protocols add overhead onto both 
end systems, represented by the need to create at least 
one process on each end machine to simulate the func- 
tionality of the ICMP. Furthermore, processing time is 
added on because raw sockets interact directly with the 
network layer and other types of sockets interact with 
the upper layers of the VP stacks. This in turn results in 
inaccuracy in the sending and arrival time of messages. 
Furthermore, as in the case of ICMP, traffic is added to 
the network. 

[0021] Systems and methods consistent with the 
present invention add intelligence to systems such as 
PBXs connected to a data network to react to changes 
in network conditions permitting communication links to 
quickly adapt to those conditions without the need for 
manual intervention and to reduce the impact of such 
systems on the network, thereby enhancing overall sys- 
tem performance. 

[0022] Methods and systems consistent with the 
present invention are provided formonitoring the quality 
of data networks and dynamically adapting its behavior 
in accordance with the condition of the network to main- 
tain QoS. 

[0023] Embodiments of the invention will now be de- 
scribed with reference to the accompanying drawings, 
in which: 

FIG. 1 illustrates a prior communication system in- 
cluding separate voice and data networks; FIG. 2 
illustrates a high level diagram of system having a 
combined voice and data network; FIG. 3 illustrates 
a more detailed diagram of the system of FIG. 2; 
FIG. 4 illustrates the contents of a message sent in 
the network of FIG. 2; 

FIG. 5 illustrates a switching matrix of the network 
of FIG. 2; 

FIG, 6 is a table used to establish channel positions 
in an IP packet sent in the network of FIG. 2; 
FIG. 7 illustrates a high level diagram of a system 
having a combined voice and data network consist- 
ent with the present invention; 
FIG. 8 illustrates a more detailed diagram of system 
of FIG. 7; 

FIG. 9 illustrates a switching matrix of the network 
of FIG. 7; 

FIG. 10 is a flow chart of steps of the process for 
transmitting a message consistent with the present 



[0024] Reference will now be made in detail to the 
construction and operation of an implementation of the 
present invention which is illustrated in the accompany- 
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ing drawings. The present invention is not limited to this 
implementation but it may be realized by other imple- 
mentations. 

A. Overview 

[0025] Systems and methods consistent with the in- 
vention provide an adaptation mechanism which can be 
utilized to monitor, maintain and control the quality of 
voice-grade communications among end-systems in a 
distributed Private Branch exchange (PBX) topology. 
Basically, incoming information from a data network is 
used to alter the behavior of a system and adjust the 
system's transmissions to the network. Such a commu- 
nication link is able to adapt rapidly to changing condi- 
tions in the network without manual intervention, there- 
by quickly enhancing the overall system performance. 
[0026] As shown in FIG. 1 , a communication system 
1 00 for an entity, such as a corporation, office, or home, 
would include a voice network 110, such as a private 
branch exchange (PBX), or a group of PBX's connected 
with each other or to a central office, and a data network 
120, such as computers 125 connected to each other 
over an Intranet and to the Internet. PBX 110 is a net- 
work that allows many voice devices 1 1 5 to share a less- 
er number of outside lines (e.g., trunk lines) for making 
external voice calls. Internal wiring in PBX 110 permits 
users within the entity to contact each other without 
sending information outside of the entity. 
[0027] As shown in FIG. 2, an entity may wish to con- 
nect voice devices 115 and computers 125 on a single 
network 200 for communication internally and externally 
to the Internet. In other words, voice network 110 and 
data network 120 would merge into a single network 
200. Typically, network 200 digitizes the data from the 
voice devices into, for example, G.711 format, and 
sends all digital data, including the voice traffic, over net- 
work 200. In other words, network 200 would use the 
same manner of transmission between computers 125 
and add additional processing to transmit data from the 
voice devices. 

[0028] FIG. 3 illustrates a typical voice and data net- 
work 200. FIG, 3 includes a data network, such as a local 
area network (LAN) based voice switch (PBX) for trans- 
mission of voice data over a data link 31 0 using Internet 
protocol (IP). Voice devices, such as internal phones 
and external lines, are connected to a respective line 
card 320 or trunk card 330 contained in a remote or ex- 
pansion cabinet 340 including a remote CPU 350 or 
shelf controller, via a respective line or channel. The 
cards 320 and 330 are selectively loaded into one of a 
plurality of slots 355 in expansion cabinet 340. Although 
a single expansion cabinet 340 is shown in FIG. 3, the 
PBX could include several expansion cabinets 340. Da- 
ta link 31 0 connects expansion cabinet 340 to a switch- 
ing matrix 360. Switching matrix 360 routes information 
from voice devices to other voice devices, internally 
through line cards 320 and externally through trunk 



cards 330. A process running on a master CPU 390 con- 
figures the present state of the switching matrix 360 over 
its backplane 380. Alternatively, master CPU 390 could 
be located apart from switching matrix 360 and the proc- 

5 ess running on master CPU 390 can configure switching 
matrix 360 over data link 310. Although each of the 
cards is shown as being loaded into an expansion cab- 
inet 340, which is remote from the switching matrix 360, 
another implementation could include some cards in the 

*o same location, or physical cabinet, as master CPU 390. 
A computer 1 25 can also be connected to data link 31 0. 
[0029] Master CPU 390 and remote CPU 350 cause 
packets of a defined size to be created for transmission 
over data link 310. These packets include information 

'5 used to route the packet to a destination and the voice 
or data information. FIG. 4 illustrates a format of a typical 
packet 400 using an Ethernet data link 310. Packet 400 
can include, for example, six bytes of a destination ad- 
dress 410, six bytes of a source address 420, 2 bytes 

20 of an indication of an ether type 430, a number of bytes 
of a data packet 440, containing data from mu Itiple voice 
devices, and 4 bytes of frame check sequence (FCS) 
data 450. Data packet 440 includes header information 
for the transmission protocol, such as 20 bytes of IP 

25 header information 441 and 4-20 bytes of UDP/TCP 
header information 442, and data 443 for N channels. 
Typically, the PBX sends 8000 packets per second that 
include voice data. 

[0030] Again referring to FIG. 3, to initiate a call to a 

30 destination voice device, a source voice device signals 
a source card ( e.g., line card 320 or trunk card 330) to 
send a message to switching matrix 360. Switching ma- 
trix 360 sets the switching fabric of the network to create 
a link between the source and destination voice devices. 

35 When a call is initiated by a device on remote cabinet 
, 340 by the device going off hook, a message is sent by 
the source device on remote cabinet 340 to a call server 
process running on master CPU 390 indicating that it is 
off hook. The call server process configures switching 

40 matrix 360 to connect the source device on remote cab- 
inet 340 to a channel that provides a dial tone to the 
newly active device. When dialing begins at the source 
device on the remote cabinet 340, indicating a desired 
destination to contact, another message identifying the 

45 dialed destination is sent to the call server process run- 
ning on master, which, in turn begins evaluating the di- 
aled number to determine if it is valid. If the call server 
process determines that the number is valid, it then be- 
gins searching for the requested destination device. 

50 When the destination device is found, the call server 
process instructs the switching matrix 360 to establish 
a connection between the source and destination devic- 
es via switching matrix 360, thereby establishing a two- 
way speech path. 

55 [0031 ] FIG. 5 illustrates a typical switching matrix 360 
for parsing and creating a packet. A multiplexer/demul- 
tiplexer 500 receives and sends IP packets over data 
link 31 0. When receiving IP packets, the multiplexer/de- 
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multiplexer 500 takes the sequentially ordered channels 
and puts them into parallel order and sends this infor- 
mation to the switch 51 0. Conversely, when transmitting 
IP packets, the multiplexer/demultiplexer 500 takes the 
parallel ordered channels from the switch 510 and plac- 
es them in sequential order to be included in an IP pack- 
et. Multiplexer/demultiplexer 500 outputs parallel data 
to a switch 51 0 or creates an I P packet. A table in switch 
510 determines the channel positions an IP packet. Of 
course, in non-blocking mode, each voice device in the 
network will have a channel available for assignment by 
the switching matrix. 

[0032] FIG. 7 illustrates a high level diagram of a net- 
work 700 consistent with the present invention . Network 
700 includes a system to transmit voice data over a data 
network, e.g., a LAN-based voice switch (PBX) over a 
data link 71 0 using Internet protocol (IP). Other data net- 
works could also be used. Voice devices, such as inter- 
nal phones and external lines, are connected to a re- 
spective line card 720 or trunk card 730 contained in an 
expansion cabinet 740, including a remote CPU 750, via 
a respective line or channel. The cards 720 and 730 are 
selectively loaded into one of a plurality of slots 755 in 
the device. Although a single expansion cabinet 740 is 
shown in FIG. 7, the PBX could include several expan- 
sion cabinets. 

[0033] Data link 710 connects expansion cabinet 740 
to a switching matrix 760. Data link 71 0 could be a single 
line or a multi-hop network. Switching matrix 760 routes 
information from voice devices to other voice devices, 
internally through line cards 720 and externally through 
trunk cards 730. 

[0034] A process running on a master CPU 790 con- 
figures the present state of the switching matrix 760 over 
its backplane 780. Alternatively, master CPU 790 could 
be located apartfrom switching matrix 760 and the proc- 
ess running on master CPU 790 can configure switching 
matrix 760 over data link 710. Although each of the 
cards are shown as being loaded into an expansion cab- 
inet 740, which is remote from the switching matrix 760, 
another implementation could include some cards in the 
same cabinet as master CPU 790. One or more com- 
puters 795 can also be connected to data link 710. 
[0035] Remote CPU 750, switching matrix 760, and 
master CPU 790 could be a number of machines, a sep- 
arate machine, or a portion of a machine. For example, 
as shown in FIG. 8, each of remote CPU 750, switching 
matrix 760, and master CPU 790 could reside in cabi- 
nets that communicate via data link 710. For example, 
each of cabinets 800, 840, and 880 includes a memory 
801, 841, and 881; secondary storage 802, 842, and 
882; a central processing unit (CPU) 790, 843, and 883; 
an input device 804, 844, and 884; a video display 805, 
845, and 885; and slots 806, 846, and 886. One skilled 
in the art will appreciate that cabinets 800, 840, and 880 
may contain additional or different components and that 
each cabinet could include the same hardware as the 
other cabinets or different hardware. Each of memories 



801, 841, and 881 includes an operating system 807, 
847, and 887; a TCP/IP protocol stack 808, 848, and 
888; a card or an active communication detection pro- 
gram 809, 849, and 889; a table management program 
s 81 0, 850, and 890; and a communication program 81 1 , 
851, and 891. 

[0036] A set of cards is loaded onto slots 806, 846 and 
886. Typically, cabinets 800, 840, and 880 would include 
at least ten slots. Each of the cabinets also includes a 

10 switching matrix. In a master/slave configuration, one of 
the cabinets (the "master cabinet"), for example cabinet 
800, would include the master CPU 790 and the switch- 
ing matrix 760. Other cabinets 840 and 880 include re- 
mote CPUs 843 and 883 and switching matrixes 855 

15 and 895, and are referred to as the remote or expansion 
cabinets. In a centralized master/slave configuration, 
only the switching matrix of the master cabinet estab- 
lishes and terminates two-way speech path connections 
and is thus referred to as the master switching matrix, 

20 in other configurations, the switching matrices of the re- 
mote cabinets could also establish and terminate two- 
way speech path connections with, for example, other 
voice devices connected to the same remote cabinet. In 
this case, the master cabinet could supervise the remote 

25 cabinets. 

[0037] As shown in FIG. 9, each of switching matrixes 
760, 855, and 895 include a multiplexer/demultiplexer 
900 and a register 910. Although register 91 0 is shown 
as separate from multiplexer/demultiplexer 900, multi- 

30 plexer/demultiplexer 900 and register 910 could be 
combined in a single device. Multiplexer/demultiplexer 
900 formats and receives packets sent over data link 
710 and outputs parallel data to a switch 920 or an IP 
packet to data link 71 0, using, for example, a field pro- 

35 grammable gate array. Register 910 stores a value that 
indicates the maximum channel number in the packet. 
This value is used to set the packet length. When a pack- 
et is received, switch 920 places the parallel data from 
the demultiplexer 900 onto the appropriate channel in 

40 the cabinet based on setup information from driver 930. 
When a packet is to be sent, switch 920 places the data 
for each active channel detected onto an input of the 
multiplexer 900 based on setup information from driver 
930 so that a packet can be formed. 

45 [0038] As will be explained below, register 91 0 main- 
tains a value based on the number of cards detected in 
a particular cabinet at a particular time. PBX applica- 
tions are capable of transmitting a number of voice 
channels on a periodic basis. For example, 320 voice 

so channels may be transmitted every 125 microseconds 
per link, giving rise to a bandwidth of 30 Mbps (voice + 
signaling, one byte per channel). Since voice packets 
occupy the largest share of this bandwidth, a system 
consistent with the invention derives certain measure- 

55 ments as an indicator of network behavior and dynam- 
ically adapts the system to insure that a certain level of 
Quality of Service is maintained at all times. 
[0039] Recent developments introduced by Nortel 
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Networks, have resulted in the capability of PBXs being 
extended, by providing distributed PBX communication 
capability over data networks. 
[0040] The Option 11C system manufactured by 
Nortel Networks is a version of the Meridian-1 System s 
constituting an integrated Private Branch Exchanges 
telephone system which has the capability of handling, 
integrated voice and data communications on a single- 
site system or directly networked with a number of other 
Option 11 C systems. Option 11C/Meridian-1 systems 10 
are mentioned as examples of systems wherein the 
principles of the invention may be advantageously used. 
[0041 J However, it will be apparent from the descrip- 
tion herein that the invention may also be used advan- 
tageously in a variety of other types of systems and net- '5 
works. 

B. Architecture 

[0042] Fig. 10 illustrates a flow chart of the steps of 20 
the operation of the network 700 including the cabinets 
of Fig. 8 in accordance with principles of the present in- 
vention. 

[0043] Initially, the table management program 810 in 
the master cabinet 800 calls card detection program 809 25 
(step 1000). At start up, card detection program 809 
polls the slots in cabinet 800 to detect whether a line or 
trunk card is loaded onto a respective slot, in some im- 
plementations, the master cabinet would be configured 
to not contain any cards, and this polling could be omit- 30 
ted. For the slots of the other cabinets, the card detec- 
tion program 809 instructs the expansion cabinets to run 
the other card detection programs 849 and 889, so as 
to detect whether a line or trunk card is loaded onto their 
respective slots and to report the results of the detection 35 
to master cabinet 800. In other implementations, the 
card detection programs 849 and 889 could detect cards 
on their respective remote cabinets without prior instruc- 
tion from master cabinet 800 and report the results of 
the detection to master cabinet 800. 40 
[0044] Based on the cards detected, table manage- 
ment program 810 creates a table defining the packet 
position index for each channel (i.e., identifying where 
information for a line will be placed in a packet) for each 
cabinet (step 1010). For example, channels for each 
card present in the remote cabinets will be assigned a 
position in the data packet. In a typical PBX setup, a 
card will have a maximum of 32 units. Typically, a voice, 
device will be connected to each unit on a given card. 
Other setups could include more or less units per card so 
for each respective card. 

[0045] A number of options are available for setting 
up a table. For example, table management program 
810 could simply assign packet positions 1-32 for the 
first card detected, packet positions 33-64 for the next 5 $ 
card detected, and so on. Alternatively, card detection 
program 809 could also detect characteristics of the 
card, such as the number of channels that a card sup- 



ports or the type of card (digital, analog, etc.), and the 
table management program 810 would assign only as 
many packet positions for a card as the card can support 
or packet positions based on the type of card. Also, if 
slot 3 contained a card, packet positions 1-96 could be 
assigned for cards 1-3, regardless if slots 1 and 2 con- 
tained cards. Similarly, the table management program 
810 could assign packet positions for channels based 
on the lowest numbered slot and the highest numbered 
slot that contains a card, for example, if a card is detect- 
ed in slots 2 and 5, packet positions 1-128 could be as- 
signed to the channels of slots 2-5, regardless if slots 3 
and 4 contained cards. These options could also be 
combined. Based on the detected information, table 
management program 81 0 also computes the maximum 
number of channels that will be sent in a packet for each 
table. 

[0046] Fig. 1 7 illustrates a card detection table 1 1 00 
consistent with the present invention when card detec- 
tion program 809 detects the number of channels that 
a card supports. In Fig. 17, a cabinet includes five slots, 
and card detection program 809 detects three cards res- 
ident in slots 1 , 3, and 4, respectively Card detection 
program 809 determines that the card in slot 1 (card 1) 
is an 8-channel card, and the cards in slots 3 and 4 
(cards 3 and 4) are each 4-channel cards. 
[0047] To populate table 1100 for this cabinet, be- 
cause card 1 is a eight channel card, the table manage- 
ment program assigns packet positions 1-8 to the first 
eight channels of card 1 and indicates a zero value to 
the 24 remaining channels, meaning that the card is de- 
tected but the channel is not used and the channel is 
not transmitted. Similarly, channels 1-4 of card 3 and 
channels 1-4 of card 4 are assigned packet positions 
9-16, respectively, and the remaining 28 channels are 
set to a zero value. A predetermined value, such as -1 , 
is assigned to all 32 channels when a card is not detect- 
ed in a particular slot (e.g., cards 2 and 5) and the chan- 
nels for the slot are not transmitted. The value currently 
stored in register 910, if any, is updated to 1 6, which is 
the maximum channel number based on the cards de- 
tected at this time. Of course, Fig. 17 merely presents 
an example of a way to populate a table. In some cir- 
cumstances, the channels in a card may be arranged in 
anon-sequential, repeating manner (for example, chan- 
nels of card 1 maybe arranged 1,9, 17, 25, 2, 10, 18, 
26, 3,...). 

[0048] Once the table management program 810 
populates a table for each remote cabinet in the net- 
work, the cabinets are synchronized so that the master 
cabinet and each remote cabinet can create and parse 
packets consistent with the respective tables (step 
1020). In one implementation, the table management 
program of the master cabinet sends all tables to table 
management programs of the other cabinets and, there- 
by, synchronizes the cabinets, or instructs the other cab- 
inets to independently create its own table. Since re- 
peatedly sending large tables could tax system resourc- 
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es and delay start up of network 700, master cabinet 
800 could send each of the other cabinets the position 
index for the first channel of each card in the respective 
other cabinets or for the first card in the respective other 
cabinets. The other cabinets would then calculate the 
position indexes of the other channels and the maximum 
number of channels. For example, to inform a cabinet 
of the structure of table 1100, cabinet 800 would send 
a message to the cabinet that card I has a position index 
beginning at 1 , card 3 has a position index beginning at 
9, and card 4 has a position index beginning at 13. The 
message could take various forms, such as a portion of 
a voice message, a portion of a call-setup message, a 
portion of connection status, or "heartbeat", message, 
or a dedicated message. In other implementations, each 
of the table management programs of the remote cabi- 
nets could calculate their own table and may inform the 
master cabinet of the format of their respective table. 
This would lessen the processing burden on the master 
cabinet. Of course, the card status information could be 
sent to the master cabinet for each remote cabinet so 
that the master cabinet can store the card status infor- 
mation and independently create or update the tables, 
as previously mentioned. 

[0049] After the cabinets are synchronized, the net- 
work is ready to process voice data and the table man- 
agement program instructs the communication program 
to begin processing voice calls (step 1030). Various 
methods are available for processing voice calls. For ex- 
ample, when a voice device requests communication, 
the cabinet including the voice device sends a request 
to the master cabinet, including an indication of a des- 
tination voice device. For ease of explanation, assume 
that this request is made with a single message, al- 
though various messages could be sent to initiate the 
link between the source and destination voice devices, 
such as those used in a signaling request or signaling 
messages. These signaling messages indicate that a 
voice device has gone off-hook and that dialing has 
been initiated. Initially the table in the master cabinet 
800 is empty, but it begins to fill as new calls are request- 
ed on the network. Upon receipt of the indication of the 
destination, the master cabinet 800 determines if the call 
is a new call requiring assignment of a new channel, i. 
e., a reconfiguration of switching matrix 760 (step 1 020). 

1 . Channel Allocation and Deallocation 

[0050] If the call is a new call, the master cabinet then 
searches for the first available channel and sets switch- 
ing matrix 760 so that the hardware in the master cabinet 
listens to the source and destination devices and ex- 
changes the voice communication between the source 
and destination devices (step 1030). Particularly, 
switching matrix 760 loads the tables corresponding to 
the source and destination cabinets so that packets will 
be created based on the cards detected. 
[0051] Simultaneously with the processing of voice 



calls, e.g., the table management program detects if 
card status has changed by, e.g., the removal of a card 
or the addition of a new card (step 1040), either contin- 
uously, based on event-notification, or at predetermined 
5 intervals. "Removal" of a card includes physical removal 
and/or operational removal, as when a card is disabled 
by a malfunction. Card detection program 809 deter- 
mines if card'status has changed in a number of ways. 
For example, each time a card is added or removed, an 
10 expansion cabinet associated with the card could send 
a message to card detection program 809 . Alternatively, 
an installer could manually notify card detection pro- 
gram 809 using an input device. In these schemes, card 
detection program 809 could determine the highest slot 
15 on which a card resides in a given cabinet and only look 
for added cards beyond this point, trading off bandwidth 
optimization for ease of processing. If card status 
changes for a particular cabinet or cabinets, the table 
management program of the master or remote cabinets 
adjusts the table in accordance with the detected 
change in card status (step 1050). 
[0052] Various options are available to adjust the ta- 
bles. The adjustment could take place on a first-come 
basis. Instead, removal of cards can be dealt with first, 
to free up available packet positions for new cards. The 
packet positions corresponding to the removed card 
could be filled by shifting the packet position indices of 
the cards following the removed card into the packet po- 
sition indices of the removed card. Instead, the packet 
position indices of the last card detected, including a 
newly-added card, could be assigned to the packet po- 
sition indices of the removed card, assuming that a new- 
ly-added card and a removed card have similar charac- 
teristics. 

[0053] When cards are added, a first-come option as- 
signs packet positions subsequent to the last card de- 
tected to the new card. This could lead to a logical as- 
signment of packet positions that is different from the 
physical configuration of slots. For example, if cards are 
detected in slots 1 and 3 at start-up, and a card is added 
to slot 2 during operation, a table consistent with the 
present invention could assign packet positions 1 -64 to 
cards 1 and 3, and packet positions 65-96 to card 2. Al- 
ternatively, the table management program could as- 
sign the packet positions from scratch, that is sequen- 
tially assign the packet positions 1 - v 96 to cards 1,2, and 
3, for example. The option used for establishing tables 
during start-up can also be employed when adjusting 
the tables or another option could be employed. The de- 
cision of which table option to use could be based on a 
detected system parameter, such as the quality of net- 
work service or a current load on a CPU. 
[0054] After the tab le(s) are adjusted, the tables of the 
remote and master cabinets are synchronized (step 
1060), in a manner similar to step 1020, and the table 
management program 810 continues to wait for card 
status to change again (step 1 040). Because the system 
can operate substantially in real-time, the sending of 
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voice messages based on the new table format could 
be inhibited until the tables of the particular remote cab- 
inet and the master cabinet are synchronized using 
handshaking. Typically, this handshaking is not re- 
quired, and the voice messages could be sent and 
cached or even lost, because the synchronization would 
take a brief time, such as less than a few seconds. 
[0055] As an example, Fig. 18 illustrates packet for- 
mation consistent with the architecture of Figs. 7-9 for 
packets sent between cabinet 840 and master cabinet 
800. Assume, for example, that unit 3 of slot 1 in cabinet 
840 wishes to communicate with unit 3 of slot 3 in cab- 
inet 840 and that the master cabinet contains the only 
switching matrix that routes calls to voice devices. Fur- 
ther assume that slot 2 of cabinet 840 is empty. 
[0056] To initialize a communication session, the call 
processing program in master cabinet 800 configures 
switching matrix 760 to connect unit 3 of slot 1 in expan- 
sion cabinet 840 with unit 3 of slot 3 in expansion cabinet 
840 in accordance with the table for the expansion cab- 
inet. An exemplary table for cabinet 840, consistent with 
the present invention, could set unit 3 of slot 1 in packet 
position 3, and unit 3 for slot 3 in packet position 35 (i. 
e., as if slot 3 were slot 2), After master cabinet 800 sets 
up the switching matrix 760, the units in cabinet 840 
send voice information. 

[0057] As shown in Fig. 18, the communication pro- 
gram in cabinet 840 "listens" to unit 3 of slot 1 and unit 
3 of slot 3 and places information from these units on, 
e.g., output positions 3 and 35 of switching matrix 844, 
respectively, based on the table for cabinet 840. Multi- 
plexer 900 then polls the switching matrix to place the 
information from the units in the appropriate packet po- 
sitions 3 and 35. Because the multiplexer 900 knows the 
maximum channel number, multiplexer 900 will indicate 
that the packet is complete upon processing the maxi- 
mum channel number. Data link 710 then transmits the 
packet to master cabinet 800, where the packet is de- 
multiplexed and sent to switching matrix 760. Switching 
matrix 760 is configured to send information from packet 
position 3 to packet position 35 and vice versa. 
[0058] As shown in Fig. 19, master cabinet 800 then 
creates an IP packet to be sent to cabinet 840. Multi- 
plexer 900 of the master cabinet then polls the switching 
matrix 760 to place the information from the packet po- 
sition 3 into packet position 35 and from packet position 
35 into packet position 3. Because the multiplexer 900 
knows the maximum channel number, multiplexer 900 
will indicate that the packet is complete upon processing 
the maximum channel number. Data link 71 0 then trans- 
mits the packet to cabinet 840, where the packet is de- 
multiplexed and sent to the appropriate voice unit. 
Thereby, voice information can be transferred between 
the source and destination voice devices. 

D. Conclusion 

[0059] Card detection allows systems and methods 



consistent with the present invention to reduce the 
amount of bandwidth required to transmit voice data in 
a network, by reducing the size (length) of the packet. 
Because card status is changed infrequently, these sys- 
5 terns and methods use a minimum amount of additional 
hardware and processing. 

[0060] Particularly, active communication program 
809 loads the tables corresponding to the source and 
destination cabinets so that packets will be created 
based on the active (busy), channels. This minimizes 
the size of the packet to include only those channels that 
are active. This reduction in size, in turn minimizes the 
bandwidth required to transmit the packet. In one imple- 
mentation the master cabinet searches forthe first avail- 
able channel when a new call request is made, however, 
the searching techniques are not limited to searching for 
the first available channel only. Typically if a previously 
active channel has gone inactive, the active communi- 
cation detection program 809 (where "communication" 
includes any communication device) will assign this 
channel to the new call. 

[0061] After the receipt of a new call request, and a 
search for an available channel, the active communica- 
tion detection program 809 will assign a channel to the 
voice device requesting a new call (step 1040). If, as 
mentioned above, the active communication detection 
program 809 locates a newly inactive channel during its 
search, it will assign this channel to the new call. If, how- 
ever, no recently inactive (idle) channels are found, the 
new call will be assigned a new inactive channel at the 
end of the table. 

[0062] In one implementation, if no new call requests 
are made and there are no existing calls on the network, 
i.e., no active channels, then no channels will be trans- 
mitted at all. If, however, a new call request is made and 
after searching for the first available channel, the active 
communication detection program 809 finds no inactive 
channel to assign to the new call, it will allocate and as- 
sign a new channel to the call. As shown in Fig. 1 1 a, the 
new call will be assigned channel 1 in the data segment 
1111 of the packet 1 1 1 0. If another call request is made 
before channel 1 goes inactive, the new call will be as- 
signed channel 2 in the data segment 1121 of the packet 
1120 as shown in Fig. 11b. This process will continue 
until the maximum number of channels on the network 
are active, and as shown in Fig. 11c, all will be included 
in the data segment 1131 of the packet 1130. Notice that 
the size of the packets 1110 - 1140 varies depending 
upon the number of active channels on the network. As 
channels are added, the packet size increases, and as 
channels are removed, the packet size decreases. As 
mentioned above, this variation in size varies the 
amount of bandwidth required to transmit the packets 
across the network, 

[0063] In another embodiment, the active communi- 
cation detection program 809 initially allocates a group 
of channels. As shown in Fig. 12a, this group is included 
in data segment 1 21 1 of a packet 1210. The group could 
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consist of a single channel, or the maximum number of 
channels, or any number in between. In addition the 
group of channels could be any variation of the channels 
located on inserted cards in a cabinet, i.e. if the fourth 
channel on the second card in a cabinet becomes ac- 
tive, then the group could consist of all channels on the 
first card and all channels up to channel 4 on the second 
card. 

[0064] The channels within the allocated group are in- 
itially inactive. As new call requests are received, the 
active communication detection program assigns the 
calls to the channels within the group. When all channels 
within the group are assigned, a new group of channels 
are allocated upon receipt of the next call request. The 
new group is included in the data segment 1221 of the 
packet 1220 as shown in Fig. 12b. This process contin- 
ues until all groups, which corresponds to all available 
channels, are assigned. When this occurs, all groups 
will be included in the data segment 1231 of a packet 
1230. 

[0065] In one embodiment of the invention, the groups 
consist of 16 channels as shown in Fig 13. Initially a first 
group of 16 inactive channels is allocated. When the 
number of active channels within the group reaches a 
number equaling the maximum number of allocated 
channels minus five, a new group is allocated. This proc- 
ess continues until all groups have been allocated. 
[0066] After the call is assigned a channel , the active 
communication detection program 809 then determines 
if the maximum number of channels to be transmitted 
has increased (step 1050). As pointed out above, if a 
recently inactive channel is found during the search for 
a channel, then the new call will be assigned to this 
channel. If this is the case, then the maximum number 
of channels to be transmitted does not increase. In con- 
trast, if no newly inactive channel is found during this 
search, then the active communication detection pro- 
gram 809 will assign a new channel to the new call re- 
quest. If this is done, the active communication detec- 
tion program 809 will increase the maximum number of 
channels to be transmitted and inform the multiplexer 
900 to set the new maximum number of channels (step 
1060). 

[0067] The active communication detection program 
809 then loads the tables corresponding to the source 
and destination cabinets so that packets will be created 
and transmitted based on the active channels (step 
1070). 

[0068] As has been previously explained, the active 
communication detection program 809 will include ac- 
tive channels in messages that are sent across the net- 
work. In addition to this, the channel detection program 
809 will end transmission of a channel once it has be- 
come inactive based on signaling from a source or des- 
tination device requesting call termination. If the active 
communication detection program 809 determines that 
there are no new call requests at step 1020, it will then 
determine if any previously active calls have become in- 



active (step 1080). If this is the case, the active commu- 
nication detection program 809 will un-assign the inac- 
tive channel so that it is no longer included in the voice 
packet (step 1090). 

5 [0069] Referring to Figs. 1 1 c and 1 1 d, if, for example, 
the maximum number of channels were active, all would 
be included in the data segment 1131 of a packet 1130. 
Assuming the maximum number of channels is greater 
than four, assume that all channels go inactive except 

10 the first four channels. These remaining active channels 
will be included in the data segment 1121 of a packet 
1130, the others having been unassigned. Note, how- 
ever, that in this example all channels except the first 
four became inactive and consequently those four are 

15 transmitted. Thus packets transmitted over the network 
during one transmission may be of a different size during 
another transmission based on call activity. 
[0070] This concept also applies to groups of chan- 
nels that have been allocated. For example, suppose 

20 three groups of 16 channels have been allocated and 
all channels are active, if a certain number become in- 
active, the active communication detection program will 
deallocate a group. In one embodiment, if the number 
of active channels falls below a number equaling the to- 

25 tal number of allocated channels minus 21 , then a group 
will be deallocated. Note that in this embodiment, this 
implies that one group of 1 6 channels is always allocat- 
ed. This is shown in Figs. 14a and 14b. Fig. 14a shows 
three groups of 1 6 channels allocated with all channels 

30 active, then channels 27-48 going inactive. Because the 
remaining number of active channels, 26, is less than 
27, which represents the total number of allocated chan- 
nels, 48, minus 21 , the third group is deallocated. The 
resulting packet 1420 to be transmitted with the remain- 

35 ing two groups in the data position 1 421 is shown in Fig. 
14 b. 

[0071] When a previously active channel is un-as- 
signed, the maximum number of transmitted channels 
is decreased, and the active communication detection 
40 program 809 will inform the multiplexer 900 to set the 
new maximum number of channels (step 1060) by set- 
ting the register 91 0. The process for sending a packet 
is then repeated. 

[0072] As outlined earlier, the present invention will 
45 assign and unassign channels as they become active 
and inactive, respectively. Figs. 10a-10c illustrate the 
steps of channel assignment and unassignment. Fig. 
10a illustrates the channel assignment process. First, a 
signaling message indicating that a voice device has 
so gone off-hook is received (step 2000). This message 
contains the IP port number connected to the data link 
71 0 for the voice device. The slot number for the voice 
device is then determined based on the location of the 
voice device (step 2010), i.e. based on which expansion 
55 cabinet the voice device is connected to. If the unit does 
not have a channel assigned to it, (step 2020), then a 
search for the first available channel will be conducted 
(step 2030). Once the channel is found, it will be as- 
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signed to the requesting voice device and marked "ac- 
tive" (step 2040). If this causes the maximum number of 
channels included in a packet to change, (step 2050), 
then the maximum number of channels will be reset to 
this new value (step 2060). A data message is then sent 
to the other cabinet indicating the physical connection 
information of the voice device such as its unit and slot 
number as well as the channel number (step 2070). This 
message could take various forms, such as a portion of 
connection status, or "heartbeat" message, or a dedi- 
cated message. The switching matrix 760 is then recon- 
figured according to the new channel assigned to the 
voice device (step 2080). 

[0073] Channel unassignment, shown in Fig. 1 0b op- 
erates in a similar manner. A signaling message is re- 
ceived indicating channel and slot number of the voice 
device that has gone inactive (step 3000). A search for 
the unit number is then conducted (step 3010). If the 
voice device had a channel assigned to it, the channel 
is unassigned and marked inactive (step 3030). If this 
changes the maximum number of channels to be includ- 
ed in transmitted packets (step 3040), then the maxi- 
mum number of channels is reset to the new value (step 
3050). A message is sent to the other cabinet indicating 
that a channel has been deallocated (step 3060). This 
message could take various forms, such as a portion of 
a voice message, a portion of a call-setup message, a 
portion of connection status, or "heartbeat" message, or 
a dedicated message. 

[0074] Figure 1 0c is an infinite loop that waits for the 
signaling messages mentioned in the above explana- 
tions. It listens for the data messages from steps 2070 
and 3060 of Figs. 10a and 10b t respectively. If a mes- 
sage is received (step 4010), then it determines if a 
channel needs to be assigned or unassigned (step 
4020). If a channel needs to be assigned, it is assigned 
(step 4040), however, if a channel needs to be unas- 
signed, it is unassigned (step 4030). If the maximum 
number of channels that is to be included in a packet to 
be transmitted changes, (step 4050), the maximum 
number of channels is reset (step 4060). 
[0075] Typically, the channel allocation and dealloca- 
tion processes of Figs. 10a and 10b run on the main 
cabinet and the process of Fig. 10c runs on the expan- 
sion cabinet. However, if the processes of 10a and 10b 
are divided among the main and expansion cabinet, 
then the process of 1 0c must be located on each cabi- 
net. This is because if the main cabinet performed the 
process of Fig. 10a (channel assignment) only, it would 
have no way of knowing when channels were unas- 
signed because channel unassignment is being done 
by the expansion cabinet, and vice versa. It should be 
noted that these three processes maybe divided among 
the main and expansion cabinets in any combination 
provided that if the processes of Figs. 10a and 10b are 
on separate cabinets, the process of Fig 10c must be 
located on all cabinets. 



2. Active Channel Reordering 

[0076] In order to further minimize the size of IP pack- 
ets transmitted over the network thus minimizing the 
5 bandwidth required to transmit those packets, the 
present invention also reorders the remaining active 
channels after previously active channels within a pack- 
et have gone inactive. Referring back to Figs. 11c and 
1 1 d, suppose all channels of packet 1 1 30 of Fig 1 1 c be- 
10 came inactive except 4. Regardless of the channel po- 
sitions of the 4 remaining channels of packet 1 1 30 of Fig 
11c, the master switching matrix will unassign the inac- 
tive channels and reorder the remaining 4 active chan- 
nels to minimize the size of the packet to be transmitted, 
'5 Thus, the new packet will take the form of the packet 
1140 of figure 11d. Therefore, after detecting and un- 
assigning channels that have become inactive, the ac- 
tive communication detection program will reorder the 
remaining active channels in order to minimize the size 
of the packet. The channels could be reordered by shift- 
ing the remaining active channels, or by reassigning the 
last active channel in the packet to the newly inactive 
position. For example; if channels 1-20 were active and 
channel 2 goes inactive, channels 3-20 could be shifted 
to the right by one channel position, or channel 20 could 
be reassigned to channel position 2. 
[0077] Active channel reordering also applies to chan- 
nel groups as shown in Fig. 15. If, for example, after 
three groups are allocated, channels become inactive 
in a random manner, the active communication detec- 
tion program 809 will reorder the remaining active chan- 
nels such that the number of allocated channel groups 
is kept to a minimum. In this example, group 3 will be 
deallocated after the reordering. 

3. Packet Formation and Transmission 

[0078] FIGs. 1 8 and 1 9 illustrate an example of packet 
formation and transmission consistent with architecture 
of Figs. 7-9 and the present Invention for packets sent 
between cabinet 840 and master cabinet 800. It should 
be noted that in this example the voice devices were 
located on the same cabinet 840, but the voice devices 
may be located on separate cabinets. As shown in Fig. 
1 8, when channel 1 0 of cabinet 840 wishes to commu- 
nicate with channel 5 of cabinet 840, assuming channel 
5 of cabinet 840 is inactive, cabinet 840 will send a re- 
quest to master cabinet 800 to assign a channel for the 
device connected to channel 10. 
[0079] Master cabinet 800 searches for an inactive 
channel and allocates, in this example, channel 4 on the 
IP packet. Master cabinet 800 then sends this message 
to cabinet 840. As the number is being dialed by the de- 
vice connected to channel 1 0 indicating that it would like 
to connect to channel 5, the master cabinet determines 
if the destination is valid. As shown in FIG. 1 9, once the 
master cabinet 800 determines that the destination is 
valid, it then searches for the first available channel and 
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assigns a channel for the destination device as well as 
sets the new maximum channel number if a new maxi- 
mum number needs to be set. In this example, the chan- 
nel for the destination device - channel 5 is assigned 
channel max. The master cabinet 800 then sends a 5 
message to cabinet 840 with this information. 
[0080] The two-way speech path is then established 
between the two devices by the master cabinet 800. The 
information received in packet position 4 is routed by the 
master cabinet 800 to packet position max. Conversely, 10 
the information received from packet position max is 
routed by the master cabinet 800 to packet position 4 
thus allowing the devices connected to channels 1 0 and 
5 to communicate with one another, 
[0081] Referring now to FIG. 20, an objective of the 15 
aforementioned development is to provide the capability 
to support communication (including voice) between 
two or more PBXs over a data network, such as an IP 
LAN 1 0. In one configuration, one PBX i 2 acts as a mas- 
ter (also referred to as the main cabinet) containing a 20 
master CPU and master switching matrix and the other 
PBXs 14 are slaved (also referred to as the expansion 
cabinets). 

[0082] Communication between the PBX cabinets 
comprises groups of voice and other packets. The voice 25 
packets are transmitted periodically, and are fully con- 
trolled by software, hardware, or both (i.e. formation and 
transmission) and may, for example, be UDP packets. 
The other packet group includes signaling, Common 
Equipment Multiplexed (CE-Mux), heartbeat and card- 30 
Ian messages. They may comprise TCP packets which 
are software controlled. 

[0083] Each PBX cabinet will typically include a 
switching device, a hardware device that provides a 
pulse code modulation (PCM), voice and data for the 35 
entire PBX system. In one implementation of such de- 
vice will have an identical number of channels on each 
side. One side will perform local switching for that par- 
ticular cabinet (voice devices connected to that cabinet). 
The other side will be dedicated to perform switching for 40 
voice devices located outside the cabinet (not connect- 
ed directly to the cabinet). 

[0084] The PBX may also be equipped with hardware 
circuitry which includes several Field-Programmable 
Gallium-Arsenide integrated circuits (FPGA) which pro- 45 
vide the certain functionality for IP links. Typically, this 
includes formatting of the PCM samples from the switch- 
ing matrix UDP packets and vice-versa; monitoring link 
performance; and controlling the packet delay buffer. 
The board may also includeseveral FIFO RAMs forbuff- so 
ering of incoming messages and two dual port RAMs for 
Packet Delay Variation buffering of incoming PCM data. 
[0085] A voice packet includes a sequence of PCM 
samples that have been captured from the IVD bus and 
packaged into a UDP/IP packet. Typically, voice packets 55 
are limited to having one Medium Access Control (MAC) 
UDP/IP destination for all samples. The FPGA stores 
one header that prefixes all outgoing voice packets. The 



voice header information is written into the PCM Header 
RAM prior to enabling voice transmission. Transmission 
of the voice packet is enabled by setting the Voice De- 
vice Enable bit in a command register. Packets are sent 
every 125 microseconds and contain up to 320 PCM 
samples. 

[0086] FIG. 21 illustrates the connections for trans- 
mission of voice packets. PBX cabinet 20, which can be 
either a main or expansion cabinet, is typically able to 
accommodate up to 320 voice channels. (The maximum 
number of channels can be configured by the user or 
the software to include a lesser or greater number of 
channels.) Daughter board 22 incorporating a FPGA IC 
is connected to cabinet 20. Each transmitted packet 24 
typically contains a maximum of 320 PCM samples. The 
transmitted packet 26 is forwarded to the network via I P 
port 28. 

[0087] Similarly, PBX cabinet 30, shown in FIG.22, 
which can be either a main or expansion cabinet incor- 
porates an IP port 38 which receives incoming packet 
36. Typically, a FPGA incorporated within board 32 is 
capable of 'receiving packets containing, for example, 
up to 320 PCM samples/channels. The received packet 
34 populated with the samples is processed by the FP- 
GA IC so that each byte of the voice frame is re-mapped 
to unique channels, one for each of the bytes, shown as 
channels 1 , 2. ..320 in cabinet 30. 

C. Performance Measurements 

[0088] According to a feature of the invention in data 
networks, Quality of Service is determined by evaluating 
at least three parameters: Latency, Packet Loss Rate, 
and Bandwidth availability. While only three factors are 
explicitly enumerated here, one of ordinary skill will ap- 
preciate that any other parameter relevant to network 
performance may figure into the determination, 
[0089] Latency is a measurement of the time that it 
takes a given packet to pass between two points in the 
network. Factors that may affect latency in a network 
include, for example, the type and number of switches, 
type and number of routers, retransmission, distance 
traveled, network congestion, and link bandwidth. Pack- 
et Loss Rate is related to the number of packets that 
become dropped from the network as a consequence 
of lack of network resources. One of the factors that may 
affect the Packet Loss Rate is the packet dropping 
mechanism used by the router, such as Random Early 
Drop. It is expressed as a ratio or percentage, as will be 
more fully described hereinafter. Bandwidth Availability 
is governed by both Latency and Packet Loss Rate, 
[0090] In order to understand the measurement meth- 
odology for QoS system requirements, the parameters 
to be measured and the interpretation of these meas- 
urements will next be described. 
[0091] Considering, as an example, a system that 
would provide voice quality in an IP LAN, the following 
requirements would have to be met: 
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Network Requirements: 
[0092] 

Packet Loss Rate of less than 1%. 

One way trip time for a packet of 3.75 millisecond. 

100 Base-T Full duplex LAN connectivity. 

System Requirements: 

[0093] Voice Packets: 

Rate: 8000 packets/second; and 
Packet Width: 320 bytes (one channel per byte, us- 
ing the G.711 standard). 

[0094] Call Set-up and Call Terminating Signalling 
Packets: 

Rate: 250/sec; and 
Width: 40 bytes. 

[0095]. Common Equipment-MUX (CE-MUX) Pack- 
ets: 

Frequency: 10/second; and 
Width: 500 bytes. 

Given the above system parameters, the required band- 
width, in Mbps, would be 29.25 Mbps, per port. 
[0096] This amount represents the bandwidth re- 
quired for one way traffic. Multiple ports can be assigned 
on the main cabinet, each communicating with a single 
expansion cabinet, thereby increasing the available ca- 
pacity. 

[0097] Several ways may be employed to obtain QoS 
parameters from the IP network application layer. A ded- 
icated client server model (TCP or UDP) can be set up 
to generate traffic. The client sends a packet and waits 
for the reply. The server will redirect the same packet 
upon reception, or send different packets. Implementa- 
tion is via either synchronous or asynchronous commu- 
nication modes. In the synchronous mode, the client 
transmits packets which may contain the system times- 
tamp as well as a counter in its packet payload. In this 
case, transmission and reception are independent of 
each other. With asynchronous implementation, the cli- 
ent awaits the reply prior to transmitting the next packet. 
In this case, a timestamp may or may not be included 
within the payload. 

[0098] Another way to monitor LAN QoS is to use the 
Internet Control Message Protocol (ICMP). In this case 
only the client is needed to control message formation 
and time of transmission. (Usually, the network server 
process will be supplied as part of the operating system 
or by a third-party, to provide an echo forthe client.) Both 
of these techniques have some real-time impact in ad- 
dition to the traffic overhead added-on in order to per- 



form the measurements. 

[0099] According to a feature of the invention hard- 
ware systems are employed to perform measurements 
using certain parameters associated with voice packets, 

5 resulting in more accurate measurements, while avoid- 
ing the above-noted shortcomings. 
[01 00] Packet Loss Counter (PLC), One way of imple- 
menting a Packet Loss Counter may be via a hardware 
register, as shown in FIG. 23a. Each voice packet is la- 

io belled (within its payload) with a sequence number. The 
receiving end monitors the sequence of packets and as 
each packet is received when a break in sequence of 
the arriving packets occurs, the counter is incremented 
by one digit. A number of packets 47a-c, 49a-c, 5 la-c 

15 forming data streams 46, 48, 50 are shown entering a 
plurality of IP ports 41, 43, 45, respectively. When a 
packet arrives out of sequence, e.g., a sequence such 
as {1 , 3,} (corresponding to packets 47a, 47b, 47c), the 
counter is incremented by 1 . A sequence such as {1 , 6, 

20 7} (corresponding to packets 49a, 49b, 49c) results in 
incrementing the counter by 1 , since packet numbers 2, 
3, 4 and 5 are missing from the data stream. A sequence 
such as {1, 3, 2} (corresponding to packets 51a, 51b, 
51c) will result In the counter being incremented by 2, 

25 since packet #2 arrives out of sequence (after packet 
#3). Thus, the value on the counter is an indicator of the 
degree of packet loss. 

[0101] FIG. 23b depicts an alternative hardware im- 
plementation of a Packet Loss Counter implementation 

30 showing data stream 52, including representative pack- 
ets 53a, 53b and 53c (numbered #1 , #2 ... #7000). Using 
the total numberof packet expected to arrive per second 
(e.g., 8000) as a reference, when each packet arrives 
(a counter will be incremented until the end of time pe- 

35 riod (second) here shown as 7000), the balance of 1 000 
comprising the packets that did not arrive at the port 
within the given time frame represents the number of 
packets lost. This measurement may be done at short 
intervals (e.g., every second). The counter is then reset 

40 to the reference number (e.g. 8000). In FIG. 23b which 
shows the packets traveling as a function of time, the 
packet loss counter will therefor read 1 000 after the first 
second. 

[0102] When the system detects the packet loss 
45 counter being incremented repeatedly over a number of 
time intervals (as in the first mentioned implementation) 
or more than zero (as in the second mentioned imple- 
mentation), the inference is that the network is congest- 
ed. As a result, one or more bandwidth optimization 
50 techniques are implemented, according to certain in- 
' ventive features to reduce the size of the voice packet. 
An alternative implementation is to use software to per- 
form packet loss measurement TCP/UDP/ICMP-gener- 
ated traffic. 

55 [0103] Latency. Latency is also an indicator that the 
network has become congested. One way of recording 
the round trip time required for voice packets to transit 
a network is to use a hardware register. Referring to FIG, 
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24, source 500 marks packet 502 as #1 (Step 1) prior 
to sending it and also starts timer 504. When the desti- 
nation machine 506 receives packet 502 (Step 2), it 
complements the value that will be transmitted on the 
next packet as packet #2 (508) back to the source (Step 
3). Upon the arrival of the #2 -marked packet (Step 4), 
the timer stops and the time difference is stored in the 
trip register. Such marking is done within the payload of 
the respective voice packets. 

[0104] An alternative implementation is to use soft- 
ware to perform the round trip time measurement using 
TCP/UDP/ICMP-generated traffic. 

Packet/Cell Delay Variation Overflow and Underflow. 

[0105] Underflows and/or overflows of the memory 
buffer (PDV Buffer) result in a change in one or both 
memory buffer pointers (read/write pointers). Half the 
buffer memory size is changed spacing between the 
pointers. Logging this count is done by hardware regis- 
ter record the number of underflow and overflow events. 
These counters can be used to determine the stte of the 
network. Underflow occurs when packets arrive slower 
than the ability of the system to process them. On the 
other hand, when voice packets arrive from the network 
faster than the system processes them, overflow occurs 
resulting in overwriting the previously received packets 
and consequently resulting in loss of data. 

Bandwidth. 

[0106] A software module provides measurement of 
bandwidth. One way of performing this measurement is 
to sum the total length of arrived packets per second 
minus the number of packets lost (obtained from the 
packet loss counter). All the transmitted and received 
packets are periodic. Another alternative to use TCP/ 
UDP/ICMP to record the round trip time to generate 
packets of different sizes and to record their round trip 
time. 

[0107] Using the parameters measured according to 
the above, software consistent with the invention is able 
to adapt the system to the behavior of the network de- 
pending on the measured values. In addition, the user 
may be provided notice about network behavior and 
voice quality after such adaptation via a terminal display, 
a printer or a voice message. 

System Reaction 

[0108] Based on the measurements described above 
obtained from the packet loss counter, packet delay va- 
ration overflow and underflow and bandwidth measure- 
ments. The system will react by taking one or two ac- 
tions, namely starting of bandwidth optimization and/or 
changing PDV Buffer size. 



Bandwidth Optimization 

[0109] A number of mechanisms can be employed 
consistent with the present invention to optimize the 

s transmission bandwidth. These include: Static Band- 
width Optimization, Adaptive Bandwidth Optimization 
and Combined Mode. With the exception of the Static 
Bandwidth Optimization method, bandwidth optimiza- 
tion is performed by reconfiguring the switching matrix 

'0 residing on the main cabinet and on the expansion cab- 
inet. In addition, a table containing the updates of the 
recent configuration of the switching matrix wili be main- 
tained on both cabinets. Issuing the commands to 
reconfigure the switching matrix can be reserved to the 

'5 main cabinet and synchronization of the table will follow. 
The new maximum number of channels is required to 
be set or both the main and expansion cabinets based 
on the new switching matrix configuration which may re- 
sult in a lesser number of channels to be transmitted by 

20 both the main and expansion cabinets. This can be 
achieved by getting a new value through the FPGA. 

1. Static Bandwidth Optimization: 

25 [0110] This feature involves the user configuring a 
value which limits the maximum number of channels 
transmitted (by, e.g., blocking or disabling several voice 
channels exceeding such limit), when the software de- 
tects problems such as packet loss. As previously de- 

30 scribed, the maximum number of channels to be trans- 
mitted is typically on the order of 320. If the packet loss 
counter is incremented in several consecutive time win- 
dows, the software will instruct the FPGA to decrement 
this value, thus reducing the number of voice channels 

35 and appropriately notify the user that bandwidth has 
been reduced. 

2. Adaptive Bandwidth Optimization: 

^0 [01 11] This feature may be implemented via several 
techniques: Empty Slot Elimination, Idle Channel Elim- 
ination, Idle Card Elimination and Priority Based Card 
Elimination: 



[0112] Typically, each slot is represented by 32 bytes 
(32 channels on the IP packet, where the slot number 
is mapped to the location of these channels in which the 

50 first slot channels will be followed by the second slot 
channels ). The QoS software can recognize the insert- 
ed cards in the expansion cabinet. A lookup table elim- 
inates empty slots and includes only channels which 
correspond to physically inserted cards in the voice 

55 packet by realigning channels, either by moving them 
from the end of the packet to an empty slot location, or 
by shifting the channels by the value of the empty slots. 
As an example, if card 1 is present, card 2 is absent, 



45 a. Empty Slot Elimination: 
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and card 3 is present, channels associated with card 4 
may be mapped into the siot #2 location in the I P packet, 
via software implementation. 

b. Idle Channel Elimination: 

[0113] The software monitors active (busy) channels 
in which communications between the main cabinet and 
a voice device on the remote cabinets is established 
based on the information provided by signalling (since 
the main cabinet performs all switching). The software 
re-maps the active channels from the end of the voice 
packet to the first available idle one (e.g., channel 
number 320 can be remapped as number 30). 

c. Idle Card Elimination: 

[01 1 4] As the software monitors the number of active 
channels on a given card, if all channels are idle for that 
card, this will be treated as if it were an empty slot (i.e., 
the card will be eliminated, as in the case of empty slot 
elimination). Once there is a request for a call setup from 
(or for) an eliminated card, that card (all or a portion) 
becomes active and all the channels for that card will be 
allocated on the packet. 

[0115] Referring now to FIG. 25a, there is shown a 
technique for Idle Card Elimination according to a fea- 
ture of the invention, 

[01 16] A packet 1 80, here shown as comprising three 
cards, 186, 188, 190, also includes an IP header 182 
and a UDP header 184. Each card has 32 channels as- 
signed to it. Certain channels are active (designated in 
the Figure as "A") and others are inactive or idle (des- 
ignated as "I"). In the example shown, all of the channels 
in the second card 1 88 are idle. With the Idle Card Elim- 
ination feature as shown in FIG. 25b, the channels as- 
sociated with the second card are eliminated, the chan- 
nels associated with the third card, 1 90, are mapped as 
channels associated with card #2 and the system rec- 
ognizes that packet 1800, containing header informa- 
tion 1 820, 1 840 now contains two cards, 1 860 and 1 880, 
each having at least some channels active. The band- 
width is thus optimized by reducing the number of chan- 
nels associated with cards in the transmitted packet. 
This can be achieved by searching the switching matrix 
status table described earlier for a group of channels 
collocated with each other with an starting index match- 
ing the index of the first channel on a given card. 
[0117] For example, if a cabinet contains cards 1 , 2 
and 3, each card being associated with 32 channels on 
the IP packet, the search would start at channel 1 and 
look at the next 32 channels to check whether all 32 
channels are idle. If not, the same process will be re- 
peated, starting at channel 33. If there is a match, i.e., 
all 32 channels are idle, these channels will be eliminat- 
ed from the IP packet. 

[01 18] If a signalling message' from a voice device lo- 
cated on the expansion cabinet requests a connection 



or channel that is not allocated within the IP packet, the 
main cabinet will search for a card corresponding with 
that voice device requesting the connection. If the card 
is physically inserted, all of the corresponding channels 
5 will be reinserted within the IP packet. (All or a partial 
number of the channels may be reinserted again.) 
[0119] The search is time dependent, i.e., the search 
can be configured to be performed periodically or within 
varying time window frames. 

w 

d. Priority Based Card Elimination: 

[01 20] The user assigns priority for each card present 
in a cabinet. 

'5 [01 21 ] When a priority based pard elimination process 
starts, the card will be eliminated from the IP packet, 
based on its assigned priority. 

[0122] Referring now to FIG. 26a, there is shown a 
technique for card priority assignment according to a 
feature of the invention. 

[0123] A packet 190, here shown as comprising three 
cards, 196, 198, 200 ( also includes an IP header 192 
and a UDP header 1 94. Each card has 32 channels as- 
signed to it. In this example, the system is configured to 
assign the highest priority to the second card 1 98, and 
the lowest priority to the first card, 196. When network 
conditions are such that bandwidth optimization needs 
to be enabled, the system drops the card having the low- 
est priority. In this particular example, channels associ- 
ated with card 196 (having the lowest priority) are 
dropped and channels associated with cards 198 and 
200 are shifted in position. As shown in FIG 1 9b, chan- 
nels associated with card 1 98 are then remapped as the 
first card, 1960, and channels associated with the third 
card are remapped as if they were associated with the 
second card, 2000. 

[0124] This process may be continued based on the 
next lower priority of the remaining cards. Thus, the 
channel associated with the third card 2000 in FIG. 26b 
was, for example, assigned the lowest priority and the 
channel associated with the second card 1 960, the high- 
est. FIG. 26c shows the resulting configuration after im- 
plementing priority based bandwidth optimization. The 
channels associated with a single card 1904 (corre- 
sponding to card 1960), 198, remains in the packet. 
Again, the number of channels associated with cards in 
the transmitted packet has been reduced. 
[0125] This can be implemented by maintaining a ta- 
ble that contains the priority assignment for each insert- 
ed card. Once bandwidth reduction is required, a search 
for the lowest priority is conducted in the table and a 
corresponding channel associated with the identified 
card (i.e., the card with the lowest priority) will be elim- 
inated from the IP packet. This elimination is done by 
reconfiguring the switching matrix and updating the ta- 
ble. 
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3. Combined Mode: 

[0126] A combination of both Static and Adaptive 
bandwidth optimization modes may also be enabled. In 
this mode, the user configures the maximum number of 
channels to transmit, along with Empty Slot Elimination, 
Idle Channel Elimination, Idle Elimination, Priority 
Based Card Elimination, or any combination thereof. 

PDV Buffer Size 

[0127] The Packet Delay Variation (PDV) buffer is 
used to buffer the packets for a certain amount of time, 
pending their ability to be processed. The PDV buffer 
length in milliseconds sets the amount of time the pack- 
ets can "wait" in the buffer. If the PDV buffer size is too 
large, the resulting delay before the packet can be proc- 
essed will also be large. On the other hand, if the buffer 
is small, there is a greater chance that the packet may 
be overwritten, resulting in a loss of data. 
[0128] Overflows and/or underflows are indicators 
that network has become degraded, resulting in lowered 
voice quality. To reduce the effect of such degradation, 
the size of the buffer can be either increased or de- 
creased, depending on the event. Software monitors the 
buffer through overflow and underflow counters and ad- 
justs the buffer accordingly. In addition, software pro- 
vides the user the capability to set the size of the buffer 
manually. 

Startup mode: 

[0129] One strategy for system startup mode would 
be the utilization of QoS parameters to measure the 
bandwidth. The number of transmission channels is in- 
creased incrementally until full system capacity is ob- 
tained. Also, the PDV buffer size is set to a default valve. 
Based on information obtained from the Underflow/ 
Overflow counters, the buffer size may be adjusted ac- 
cordingly. 

[0130] Based on another strategy, the System may 
start up by transmitting the maximum number of chan- 
nels within the voice packet and based on measure- 
ments of QoS parameters, the number of channels may 
be reduced accordingly. 

Software Design Methodology 

Parameter Measurement Techniques 

[01 31 ] The measurements are calculated for presen- 
tation to the user upon his or her request to be stored 
for later analysis of system behavior. 

Packet Loss Rate: 

[0132] Regardless of the type of hardware used for 
implementing the PLC, the following assumptions are 



made (by way of example only, and are not intended to 
be limiting in any way). First: on a low traffic network, 
the Packet Loss Counter (PLC t ) maps, one-to-one, the 
number of packets lost. Second: that the packets will not 
5 be arriving out of order (i.e. all packets will follow the 
same path from source to desti nation) . Third: 8000 voice 
packets are transmitted per second. At a given time, the 
packet loss rate (Pl_t) is: 

PL t = 100xPLC t 
8000 x A t 

where 6+ is the interval between the current and previous 
measurement, in seconds. 

[0133] Provided the second PLC hardware imple- 
mentation is used (i.e. measuring the number of packets 
received, as shown in FIG. 23b), the measurement will 
be performed every second. Consequently, ^ = 1 . If the 
first PLC implementation is used, either a fixed or chang- 
ing time window can be used to read the hardware reg- 
ister for obtaining the measurement. 
[0134] An alternative way to obtain these measure- 
ments is via software implementation using TCP/UDP/ 
ICMP-generated traffic. The packet loss, p , is computed 
from the ratio of the number of packets received, R, with 
respect to the number of packets transmitted, T, 

T 

and the percentage is: 

PZ-=[(1 -p)x100J/A t . 

where Af is the time window size for this measurement 
which can be either a fixed or varying window, 
[0135] Accuracy of these measurements is depend- 
ent on the volume of the traffic generated over a period 
of time. 

[0136] Latency: Assuming by way of example only 
that incoming and outgoing packets follow the same 
path, i.e. the network latency is the same in both direc- 
tions, at a given time, t, the one way latency (L t ) intro- 
duced by the network is: 

rtt t 

l^ = — - (processing time) 

where rff, is the round trip time for the packet transmis- 
sion, For hardware implementation of round trip time 
measurement, the processing time is negligible, and 
thus assumed to be zero. An alternative way to obtain 
these measurements is a software implementation us- 
ing TCP/UDP/l CMP- gene rated traffic. For software im- 
plementation, accuracy of these measurements is de- 
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pendent on the volume of the traffic generated overtime, 
as well as processing time. 

[0137] Since voice packets are transmitted and re- 
ceived periodically, a more accurate measurement can 
be obtained by calculating the time difference between 
the arrival of two consecutive packets. 

Packet Delay Variation: 

[0138] Since streaming of voice packets are timely- 
dependent, this parameter may be used to monitor voice 
quality. 

[0139] If a hardware implementation is used, an indi- 
cation of packet delay variation is any increment of over- 
flow and/or underflow in the packet delay variation reg- 
ister. Polling of this register can be done via either a fixed 
or varying time window. 

[01 40] The Packet Delay Variation may be defined as 
the difference between the average (moving/changing/ 
incrementing history window) arrival times and the ar- 
rival times of the latest packet. Consequently, an alter- 
native way to obtain these measurements is a software 
implementation using TCP/UDP/ICMP-generated traf- 
fic. The minimum, maximum and average values of the 
packet arrival times are recorded for a specific period of 
time in a file, memory or a buffer. 

Bandwidth: 

[0141] Assuming that outgoing packets will always 
follow the same path, at a given time, t, the bandwidth, 
BW t is: 

[0142] BW t = [(sum of size of packets transmitted) - 
size of packet loss)]/^ 

where Aj is the duration of the measurement interval in 
seconds. 

[0143] An alternative way to obtain bandwidth meas- 
urements is to use TCP/UDP/ICMP-generated traffic. 
[0144] For simplicity, and to minimize the add-on traf- 
fic as well as to reduce the computational overhead on 
the CPU, two TCP/UDP/ICMP packets of different sizes 
are sent periodically. These messages are labelled as 
small and large packets (depending on their respective 
sizes). After the reception of both echo replies, the dif- 
ference \ between the round trip times, rtt t of the large 
and small packets is computed, as follows: 

where rflj and rtt s are the round trip times for the large 
and small packets, respectively. Another parameter 
used to compute BLVis the difference in packet lengths: 

where L f is the length of the large packet and L s is the 



length of the small packet, in bits. Finally, the throughput 
is 

5 BW= 

T 

Bandwidth Restoration 

10 [0145] The software will monitor the availability of 
bandwidths measured as described in the previous sec- 
tion and the PLC for a period of time. Once a repetitive 
reading from the PLC indicates that no additional pack- 
ets have been lost, bandwidth optimization mechanisms 
*5 may then be reversed gradually. Bandwidth is then mon- 
itored continually to determine if any degradation has 
occurred. The increment is done gradually up to the 
maximum number of channels available on the system. 
The time window used to monitor the PLC and band- 
width measurements can be of a fixed or changing size. 

PDV Buffer Size Restoration 

[0146] As software will monitor the PDV Underflow/ 
Overflow counters for a period of time, when it detects 
that there is no change in either counter, software will 
reduce the size of the buffer gradually and continue 
monitoring under either of these counters increments. 

User Interface 

[01 47] The QoS monitoring functionality is interpreted 
as rating the Quality of Service of the data network 
based on predefined thresholds. Ratings and average 
values are displayed on the user terminal and also are 
stored, for example, in a fixed-size log file. In addition, 
the software permits changing and configuring several 
parameters, such as PDV buffer size, maximum number 
of channel and thresholds. 

[0148] Control of QoS monitoring can be maintained 
on either the main or the expansion cabinet. If any QoS 
parameter goes below a predefined threshold level, ap- 
propriate warning messages are generated and com- 
municated to the user on a display, printer or via a mes- 
saging system, such as a pager The thresholds used 
are either default values or user-defined new values. 
[0149] The parameters displayed include: 

RTD (Round Trip Delay). 
Packet errors (Loss). 
PDV buffer underflows. 
PDV Buffer underflows. 

[0150] Examples of rating thresholds and the accom- 
panying respective message displays are as follows: 
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Round Trip Time Delay (RTD) 


Threshold 


Message Displayed 


<10 ms 


Excellent 


<15 ms 


Good 


<20 ms 


Fair 


>20 ms 


Poor 




Packet Loss (% of errors) 


Threshold 


Displayed Message 


<1% 


Excellent 


<2% 


Good 


<3% 


Fair 


>3% 


Poor 



[01 51 ] Obviously, these thresholds are exemplary on- 
ly and may be adjusted to suit user requirements. Since 
multiple ports are available on the main cabinet, the user 
may specify the port or ports to be monitored. Configu- 25 
ration of each port may be done collectively or independ- 
ently. 

Detailed Architecture 

30 

[0152] The QoS monitoring software component may 
be implemented in several ways. One approach in- 
volves dedicating a single task (process) on the main 
cabinet to poll the hardware registers, and perform the 
actions. In this case, the task is responsible for monitor- 35 
ing all IP ports available on the cabinet. A second ap- 
proach is to create a separate task per port. In either 
case, the task performs similar functionality. Collecting 
the QoS parameters from the expansion cabinet is done 
in the same way with the exception that these parame- *o 
ters are sent to the main cabinet to perform actions and 
display this information to the user. 
[0153] The QoS monitoring task is created on the 
main and the expansion cabinets at start up, and are 
running all the time. Upon initiating the task on the main 45 
cabinet, a message queue is created to accept com- 
mands from the user to display the current measure- 
ment statistics of the system's behavior. Both tasks then 
start polling hardware registers using a default fixed or 
changing time window. The percentage of packet loss so 
is computed, and compared with a predetermined 
threshold. To ensure the accuracy of the measure- 
ments, the status of the link between the two cabinets 
is checked regularly based on the smallest measure- 
ment window obtained from a database file stored on 55 
the system computer 

[0154] To maintain consistency, the size of the PDV 
buffer, measurement time windows, and thresholds for 



each port is maintained in the database file. This file con- 
tains one entry for each Main Cabinet port and one entry 
for each Expansion Cabinet port. 
[0155] All bandwidth optimization mechanisms can 
start on either end of the network as long as all related 
information is transmitted to the other end. The user has 
the flexibility to choose which technique to use. 
[0156] The empty slot elimination bandwidth mecha- 
nism is based on card detection. The slot number of the 
inserted cards in the expansion cabinet is obtained. An 
array of size 10 is created. Its index represents the log- 
ical slot number and its value represents the physically 
inserted slot number (e.g., if cards 1 and 3 are inserted, 
the array is Slot[1] = 1 , Slot[2] = 3, Slop] = null). On the 
main cabinet side generally only the XIVD values are 
calculated from the array. 

[0157] The empty channel elimination bandwidth 
mechanism is based on monitoring the activity of all 
channels. This is achieved by creating an array of 320 
representing the expansion physical channels and 
marking the active ones based on the information pro- 
vided from signalling. A channel can only be marked 
once. When blocking is introduced, and a new connec- 
tion request is made for a channel that exceeds the 
blocking range, the array is searched for a non-active 
channel and the corresponding array element is marked 
with the new channel number. For example, if the max- 
imum number of channels is set by the user, to be 1 80, 
and if channel 200 is requesting connection and element 
indexed 1 00 is not marked, channel 200 will be assigned 
logical channel 100. On the expansion side, the NIVD 
unit will be the logical value of the newly-assigned chan- 
nel and the XIVD is the actual unit from the card. In the 
main cabinet the XIVD unit will be obtained from the ar- 
ray, 

[01 58] Changing the packet size for any of the optimi- 
zation techniques implemented involves setting the lo- 
cal FPGA register with the maximum number of chan- 
nels to transmit and notifying the other side of the new 
bandwidth so that it can set its FPGA register. This is 
done either by directly setting the FPGA of the expan- 
sion cabinet using the Remote Call Procedure (RPC) 
protocol or sending a new TCP or UDP message and 
implementing a server on the expansion cabinet to wait 
for these types of messages and setting the FPGA with 
the new values or include this message with other ex- 
isting messaging systems (e.g., heartbeat, signalling, 
cardlan). 

[01 59] Similarly, setting the PDV buffer size, using ei- 
ther RPC or sending the new value to the other side in 
a message can be used. The difference in this case is 
that setting is done independently, i.e., changing the 
buffer size on the main cabinet may not require chang- 
ing the size of the expansion cabinet. Software imple- 
mentations comprising features of the present invention 
may be divided into three processes: Packet Loss Coun- 
ter, Packet Delay Variation and Bandwidth Optimization. 
[0160] Referring to FIG. 27, there is shown a flow 
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chart depicting a process for measuring the amount of 
packet loss as an adjunct to enabling bandwidth optimi- 
zation. A complete packet interval needed to fill the 
Packet Loss Counter hardware register described ear- 
lier is awaited (step 60). Next, the Packet Loss Counter 5 
(PLC) is read (step 62). If the PLC reading exceeds a 
predetermined threshold (expressed as PLC > Thr1) 
and, if the current PLC reading compared to the previ- 
ous PLC reading is greater than zero (A PLC > 0) (step 
64), the PLC flag is incremented by 1 (step 66). Other- 10 
wise, the process of waiting for a complete packet inter- 
val is repeated (step 60). After the PLC flag is increment- 
ed (step 66), the PLC flag reading is compared to a sec- 
ond predetermined threshold (PLC_Flag>thr2, step 68). 
If the value of the flag exceeds that of the threshold, 'the 15 
network is inferred congested and the program pro- 
ceeds to enable bandwidth optimization (step 70). Ena- 
blement also causes the PLC flag to be reset to zero 
(step 72) at which point the system and awaits a new 
complete packet interval (step 60). 20 
[01 61 ] FIG. 28 shows a flow chart for measuring pack- 
et delay variation. As previously mentioned, packets ar- 
riving faster than the current system set up to process 
them can result in loss of data. Conversely, packets ar- 
riving too slowly may result in gaps in the data, notice- 25 
able as pauses during voice conversations. 
[0162] A complete packet interval needed to fill the 
Packet Delay Variation (PDV) hardware buffer, de- 
scribed earlier, is awaited (step 70). The number of 
events of overflow and underflow in the PDV buffer is 30 
then read (step 72) and if there is any overflow (Over- 
Flow>0, step 74), value of the overflow variable is incre- 
mented (step 76). The PDV_OF value is then compared 
with a predetermined overflow threshold value 
(PDV_OF>OF_Thr, step 78). If the PDV_OF value ex- 35 
ceeds that of OF_Thr, the PDV_OF variable is reset to 
zero (step 82). 

[0163] The PDV overflow threshold has not been ex- 
ceeded (step 78), a new packet interval time slot is 
awaited (step 70) and the steps are repeated. 40 
[0164] With continuing reference to FIG. 28, no over- 
flow is detected (step 74) the packet underflow count is 
compared to zero (step 84). If the count does not exceed 
zero, a new packet interval branches back to step 70 
time slot is awaited. On the other hand, if the underflow 
count is greater than zero, the underflow variable 
PDFJJF is incremented (step 86). Program step 88 is 
a logic step which compares the underflow variable from 
step 86 to a predetermined underflow threshold 
(UF.Thr). If PDVJJF is greater than UF_Thr, the buffer so 
size is reduced at step 90 and the PDV_UF variable is 
reset to zero in step 92. If PDVJJF is less than UF_Thr, 
at logical step 88, the program branches back to step 
70 to await the next packet interval. Upon resetting in 
step 92, the program also branches back to step 70. ss 
[0165] FIG. 29 illustrates a flow chart showing imple- 
mentation of bandwidth optimization. An indication from 
the program that bandwidth optimization is to be imple- 



mented, such as the enable bandwidth optimization pro- 
gram command 70 shown in FIG. 27 initiates the proc- 
ess. 

[01 66] If adaptive bandwidth optimization is not to be 
enabled, a decision is made whether or not to enable 
static bandwidth optimization (step 1 02). If no, a degrad- 
ed network condition is reported to the user (step 104). 
If Static BwOpt is enabled (step 102), static bandwidth 
optimization is enabled (step 108). If adaptive band- 
width optimization is to be enabled (step 100), the pro- 
gram (Adaptive BWOpt enabled). 
[0167] Adaptation mecrfanism systems and methods 
consistent with the present invention reduce the amount 
of bandwidth required to transmit voice data in a net- 
work. Because transmission is limited to active chan- 
nels, the bandwidth is utilized in an efficient manner re- 
gardless of the number of physical cards present on the 
network. 

[0168] It will be seen that the present invention can, 
for example, be implemented in architecture other than 
centralized, master/slave configuration. More than one 
PBX can be provided, such as in a distributed PBX en- 
vironment with multiple cabinets performing at least one 
of the function of the centralized master cabinet. Back- 
up cabinets could also be provided to prevent commu- 
nication disruption in the event of a breakdown of a pri- 
mary cabinet. 

[0169] In addition, the system and method of the 
present invention could be implemented as part of a Me- 
ridian-1 system manufactured by Nortel Networks and 
include Option 11C cabinets. Also, the foregoing de- 
scription is based on a client-server architecture. 
[0170] Additionally, although aspects of the present 
invention are described as being stored in memory, one 
skilled in the art will appreciate that these aspects can 
also be stored on other types of computer-readable me- 
dia, such as secondary storage devices, like hard disks, 
floppy disks, or CD-ROM; a carrier wave from the Inter- 
net; or other forms of RAM or ROM. 
[0171] Also, the foregoing description is based on a 
client-server architecture, but those skilled in the art will 
recognize that a peer-to-peer architecture may be used 
consistent with the invention. Moreover, although the 
described implementation includes hardware and soft- 
ware, the invention may be implemented only in hard- 
ware or only in software. 



Claims 

1. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising the steps of: 

identifying a parameter associated with a data 
packet transported across the network; 
measuring the parameter; and 
enabling optimization of the network bandwidth 
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when said measured parameter differs from a 
predetermined value. 

2. Apparatus for dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising: 

first and second PBX cabinets interconnected 
in a local area network configuration for send- 
ing and receiving data packets; 
a register in connection with at least one of said 
cabinets for storing a value associated with a 
given packet; 

a comparator for comparing said value with a 
predetermined value; and 
an optimization mechanism for adjusting the 
bandwidth of the network when said measured 
value differs from a predetermined value. 

3. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 1 , wherein: 

said parameter comprises a sequence 
number associated with the payload portion of said 
data packet. 

4. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim I, wherein: 

said parameter comprises measurement of 
the difference in arrival times of packets sent across 
the network and back between a first packet and a 
second packet, 

5. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 1 , wherein: 

said parameter comprises measurement of 
the difference in arrival times of packets sent across 
the network and back between the average value 
of arrival times of a group of packets and a second 
packet. 

6. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 3, further comprising 
the substep of: 

storing the sequence numbers of data pack- 
ets in a register. 

7. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 6 furthercomprising 
the substep of: 

storing sequence numbers associated with 
successive data packets in the register. 

8. A method of dynamically adapting a PBX network 



to maintain a Quality of Service level in the network 
comprising as set forth in claim 7 further comprising 
the substep of: 

monitoring the sequence of sequence num- 
5 bers associated with successive data packets 
stored. 

9. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 

10 comprising as set forth in claim 8 further comprising 
the substep of: 

incrementing a counter in the register by a 
count of one when the sequence numbers of 
15 successive data packets stored are in sequen- 

tial order; and 

incrementing the counter by a count greater 
than one when the sequence numbers of suc- 
cessive data packets stored are out of sequen- 
ce tial order. 

10. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as setforth in claim 9, furthercomprising 

25 the substep of: 

initiating bandwidth optimization when said 
counter count is incremented by a count greater 
than one. 

30 11. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 10, wherein: 

said bandwidth optimization comprises static 
optimization. 

35 

12. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 11 , wherein: 

said static optimization comprises limiting the 
40 number of channels available on the network. 

13. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 10, wherein: 

45 said bandwidth optimization comprises adap- 

tive optimization. 

14. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 

so comprising as set forth in claim 13, wherein: 

said adaptive optimization comprises the step 
of determining which channels are physically rep- 
resented by cards connected to a PBX network cab- 
inet. 

55 

15. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising as set forth in claim 13, wherein; 
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said adaptive optimization comprises the step 
of determining whether a channel is inactive and re- 
mapping an active channel to an available inactive 
one. 

16. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising the steps of: 

monitoring the network cards capable of being 
physically connected to a cabinet; 
determining which cards are not present; and 
associating channels of a packet with only the 
cards which are physically present. 

17. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising the steps of: 

monitoring channels on a network to determine 
whether any channels are idle; and 
mapping active channels from the end of a 
packet to an available idle channel. 

18. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising the steps of: 

monitoring channels associated with a plurality 
of network cards; 

determining whether all channels in a given 
card are idle; and 

eliminating a card containing associated chan- 
nels which are all idle from an Internet Protocol 
packet. 

19. A method of dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising the steps of: 

assigning various priorities to a plurality of net- 
work cards; 

monitoring the status of the network; and 
removing a card having the lowest priority in or- 
der to optimize the status of the network. 

20. Apparatus for dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising: 



value. 

21 . Apparatus for dynamically adapting a PBX network- 
to maintain a Quality of Service level in the network 
5 comprising: 

a monitoring system which monitors the net- 
work cards capable of being physically con- 
nected to a cabinet; 
10 the monitoring system determines which cards 

are not present and associates channels of a 
packet with only the cards which are physically 
present. 

*5 22. Apparatus for dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 
comprising: 

monitoring apparatus which monitors chan- 
nels on a network to determine whether any chan- 

20 nels are idle and maps active channels from the end 
of a packet to an available idle channel. 

23. Apparatus for dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 

25 comprising: 

monitoring apparatus which monitors chan- 
nels associated with a plurality of network cards, de- 
termines whether all channels in a given card are 
idle, and eliminates a card containing associated 

30 channels which are all idle from an Internet Protocol 
packet. 

24. Apparatus for dynamically adapting a PBX network 
to maintain a Quality of Service level in the network 

35 comprising: 

an assigning system which assigns various pri- 
orities to a plurality of network cards; and 
a monitoring system which monitors the status 
<*o of the network and removes a card having the 

lowest priority to thereby optimize the status of 
the 



45 



a parameter identifying mechanism for identify- 
ing a parameter associated with a data packet 
transported across the network; 
a parameter measuring device for measuring 
the parameter; and 55 
an optimization enabling device for optimizing 
the bandwidth of the network when said meas- 
ured parameter differs from a predetermined 
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